1. Field of the Invention
The present invention relates generally to a remote access service using Universal Plug and Play (UpnP), which is a home network middleware protocol, and more particularly, to a method and an apparatus for managing access authority information required for a remote access between a home network and an outside device or between home networks.
2. Description of the Related Art
In general, a home network is configured by a private network based on the Internet Protocol (IP), and controls such that all types of various devices such as a Personal Computer (PC), an intelligent product, a wireless device, and the like are connected with one network through a common virtual computing environment called middleware.
The middleware connects various digital devices by a peer-to-peer method to enable communication between the devices to be possible. As the middleware, a Home AV Interoperability (HAVI), a UPnP device, a Java Intelligent Network Infra-structure (Jini), an Home Wide Web (HWW), and the like are proposed.
After a Plug and Play (PnP) function is added to a current operating system, it is much easier to install and setup peripheral devices of the PC. UPnP is a technology which enables network devices such as various electric home appliances, a network printer, and an Internet gate to perform a networking, especially a home networking, by extending the convenient function to a whole network, based on Internet standard technology such as a Transmission Control Protocol/Internet Protocol (TCP/IP), a HyperText Transfer Protocol (HTTP), and an eXtensible Markup Language (XML).
UPnP includes a Controlled Device (CD), which is a device connected to the home network to be controlled, and a Control Point (CP) to control the CD. Further, the UPnP network communicates between the CD and the CP by using the UPnP protocol stack structure including an Internet protocol such as the TCP/IP, HTTP, and technology such as XML, and Simple Object Access Protocol (SOAP).
FIG. 1 illustrates a general UPnP remote access architecture. The UPnP remote access architecture shown in FIG. 1 is from a document of Remote Access Architecture version 1.0 of the UPnP Forum.
Referring to FIG. 1, a remote access client 1100 includes a CP 1130, a Remote Access Discovery Agent (RADA) 1110, an RAC 1120, a device 1140, and an Remote Access Transport Agent (RATA). A remote access server 1200 includes an RADA 1210, an RAS 1220, and an RATA 1230. A home device 1300 and a management console 1400 are connected to the remote access server 1200 by a LAN.
The RAC 1120 and the RADA 1110 of the remote access client 1100, and the RAS 1220 and the RADA 1210 of the remote access server 1200 refer to a UPnP RA device.
A RADASync CP 1113 and a RADASync CP 1212 refer to a remote access-related UPnP CP, and a RADASync 1112, a RATAConfig 1224, a RADASync 1211, a RADAConfig 1223, a RATAConfig 1121, and an Inbound Connection Config 1221 refer to a remote access-related UPnP service.
An RADA Listener/Relay 1222 and an RADA Listener/Relay 1111 refer to a support component of the RADA, and the CP and the device 1140 refer to the UPnP CP, the device, and the service, which are not related to the remote access.
A current basic UPnP architecture (version 1.0) is operated in a UPnP device discovery, and the like, based on an Simple Service Discovery Protocol (SSDP), and the SSDP is a protocol of basically using an IP multicast. However, since a current IP multicast cannot guarantee normal operation in an Internet range, the control of the UPnP device is also impossible through the Internet. Therefore, the UPnP remote access architecture is proposed in order to enable the UPnP device and the CP device to be operated as if they are physically located in the home network even when they must be accessed through the Internet.
As shown in FIG. 1, the UPnP remote access architecture defines the UPnP remote access server 1200, the UPnP remote access client 1100, and the UPnP RADA devices 1110 and 1220, and generates an RAT channel through the RATA 1150 and 1230. The physical remote access server 1200 and the remote access client 1100 commonly include the UPnP RADA 1110 and 1220, and include the UPnP RAC 1120 and the UPnP RAS 1220, respectively.
The UPnP RADA 1110 and 1220 devices can synchronize a list of the UPnP device operating on the home network in which the remote access server 1200 is included, with a list of the UPnP device included in the remote access client 1100. Also, the UPnP RADA 1110 and 1220 devices can control an SSDP message so that the UPnP CP device on the home network in which the UPnP RADA 1110 and 1220 devices are included can find the UPnP device on the remote network. The UPnP CP device, which has found the UPnP device on the remote network, transmits a control message in order to use a service provided by a corresponding device, and the message is directly delivered to the UPnP device on the remote network through a transport channel.
In the UPnP remote access architecture, a service for a remote access transport channel setup is performed by a process of setting the Inbound Connection Configuration (ICC) 1221, the Dynamic DNS (DDNS), and an Session Traversal Utilities (STUN) server address, and reporting information (related to NAT, and whether the RAS and the IGD are in the same place) collected by an STUN client to a Management Console (MC) 1400.
The MC 1400 performs a remote access-related setup and monitors an operation. The RATAConfig 1121 and 1223 service is a common service of the RAS 1220/RAC 1120. The MC 1400 sets a required parameter by calling an RATA 1230 setup service interface, based on the information reported by the ICC 1221. It is assumed that the service is performed when both RAS 1220 and RAC 1120 are in the home.
When the service for the RADA 1110 and 1210 setup is provided, the RADAConfig sets filters for the RADA 1110 and 1210. It is determined whether a filtering of information regarding an export/import filter-RAC/home device is needed. The RADA 1110 and 1210 can synchronize a tree-type network image with regard to the UPnP device lists of local and remote networks. When the device is added to the local network, an AddRemoteDevice( ) interface of the remote network is called, and the newly added device is added to a remote network node of the network image. The reverse is also the same as the above case.
When the device joins or leaves the network while RADAListener 1111 and 1112 monitor an SSDP message, function modules provide the SSDP message to the RADA 1110 and 1210. The RADARelay 1111 and 1222 reconstruct an action of the remote RADA to the SSDP message, transmit the SSDP message to the local network, and then respond to an SSDP query (M-Search) with regard to the remote device of the local device.
Referring to FIG. 1, an operation of the UPnP remote access architecture is as follows.
1. The MC 1400 obtains an outside IP address from the IGD, calls an ICC service 1221 interface of the RAS 1220, and then sets STUN server and DDNS server addresses, and the like.
2. The MC 1400 calls the RATAConfig 1121 and 1223 services of the RAS 1220 and RAC 1120, and sets a parameter (Profile) for an RA transport channel (generally, a VPN). In step 2, it is assumed that the RAS 1220 and the RAC 1120 are on the same network.
3. The RAC 1120 moving to an outside network generates the RAT connection, based on the RATAConfig 1121 information set in step 2.
4. The RADA 1110 and 1210 of the RAC 1120 and the RAS 1220 synchronize the network image through the RAT channel generated in step 3. The RAS 1220 can set the filter of the device list of the local network disclosed to the outside through the RADAConfig service as shown in FIG. 1
5. The RAC 1120 finds the service of the RAS 1220 (The RAC finds the service of the RAS from the synchronized network image). A service provided by the device, which has been filtered by the RADAConfig service of the RAS 1220, cannot be found.
6. The RAC 1120 can directly make a request for the found service through the RAT channel. The RAS 1220 then functions only as a router.
The home device provides the processing and result in response to the request of the actual RAC 1120.
According to the above procedure, the RAC requires access authority for the RAC for the connection between RAC-RAS. Thus, a user sets the access authority to the RAS for the RAC through the RADAConfig procedure by using the MC 1400 in advance. Accordingly, when a particular RAC desires to access the RAS, an advance registration procedure is necessary, and the procedure is performed in the home. As a result, when the user is outside the home, it is impossible to access.
FIG. 2 is an illustrates a situation in which an access authority setup cannot be performed in a conventional remote access system. Referring to FIG. 2, the situation in which the access authority setup cannot be performed in the remote access system is described. For example, when a user A 230 meets a user B 240 outside of the home, and user A 230 desires to transmit presentation data, which are in the home of user A, to user B 240, user B 240 cannot access a file server 250 in the home network of user A 230 if user B 240 is not registered to the RAS 220. As described above, when a user is located at the outside of the home, even if the user desires to give an access authority to another user in order to access the RAS 220 of the user, an access authority setup is impossible because of the inability to access the MC 210 in the home.